As the use of the Internet and the World Wide Web (“Web”) has become widespread, it is increasingly common for users to access and use various types of capabilities provided by remote computing systems over the Web, including to search for, shop for and order items (such as products, services and/or information) that are for purchase, rent, lease, license, trade, evaluation, sampling, subscription to, etc. In addition to such user-initiated interactions, software programs on remote computing systems may also interact for various purposes and in various ways. For example, there is growing use of the Web to provide so-called “Web services,” which typically involve the programmatic interaction of remote applications to exchange information via defined APIs (“application program interfaces”). Web services allow heterogeneous applications and computers to interact, and may be defined and implemented using a variety of underlying protocols and techniques. For example, some Web service implementations return data in XML (“eXtensible Markup Language”) format using HTTP (“HyperText Transport Protocol”) in response to a Web service invocation request specified as a URI (“Uniform Resource Identifier”), such as a URL (“Uniform Resource Locator”) that includes a specified operation and one or more query parameters. Such URI-based invocation requests may, for example, be based on the use of XML over HTTP (e.g., as part of the REpresentational State Transfer, or “REST”, distributed interaction model that focuses on resources). In other implementations, additional underlying protocols are used for various purposes, such as SOAP (“Simple Object Access Protocol”) for standard message exchange, WSDL (“Web Services Description Language”) for description of service invocations, and UDDI (“Universal Description, Discovery, and Integration service”) for discovery of available services. The use of Web services to enable software programs to interact is in some situations referred to as one example of a service-oriented architecture.
While the use of remote software services by software programs provides various benefits, various problems also exist. For example, each software service will typically provide a distinct interface for others to use when accessing the service, such that a software program using multiple remote services may need to manage and support various different interfaces for those multiple services. In addition, as a service evolves or otherwise changes, multiple versions of the service may be created, with the interface to the service similarly changing for some or all of the service versions so as to create multiple distinct versions of the interface. If a provider of such a changing service does not continue to support previous versions of the service, a client software program that uses the service may further need to be modified to adapt to the newest version of the service, such as to use the newest service interface, thus creating further difficulties for the client software program's creator and users. Alternatively, the provider of the changing service may minimize that problem by continuing to provide and support some or all of the previous versions of the service, but such continued support is difficult and expensive for the service provider. For example, the service provider may need to maintain separate software code for each such supported version of the service, which increases the storage needs, maintenance costs, and testing requirements for the service provider. Furthermore, in such situations, the service provider may need to create and maintain a separate front-end handler that receives each client request and directs the request to the appropriate separate software code for the service version for that request, which increases the computing nodes and development costs for the service provider.